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1.0  INTRODUCTION  AND  SCOPE 


The  Continuous  Learning  Braneh,  Warfighter  Readiness  Researeh  Division  of  Air  Foree 
Researeh  Laboratory’s  1\V^  Human  Performance  Wing  (711HPW/RHAS),  has  sought  to 
integrate  live,  virtual  and  constructive  (LVC)  simulation  technologies  with  advanced,  robust  field 
training  exercises,  and  to  ultimately  create  a  deployable  LVC  capability  to  be  used  for  training 
and  exercise  control.  The  goal  of  the  Deployable  Training  Technologies  (DTT)  project,  intended 
as  the  next  step  in  a  continuing  deployable  LVC  research  effort,  was  to  integrate  training 
technologies  into  a  ruggedized  field  platform  that  the  Air  Force  Research  Laboratory  (AFRL) 
could  deploy  to  training  exercises  in  the  U.S.  and  around  the  world.  The  effort  included 
assimilating  several  pieces  of  AFRL-developed  software  that  manages  and  supports  training 
exercises  into  a  deployable  live,  virtual  and  constructive  (DLVC)  platform.  The  DLVC  platform 
is  a  simulation  development  and  prototype  production  environment  built  for  the  State  of  Ohio  by 
Cubic  Corporation  of  San  Diego  and  Dayton  and  SelectTech  Geospatial  Advanced 
Manufacturing  of  Springfield  and  operated  by  the  Wright  State  Research  Institute  (WSRI). 

As  part  of  the  DTT  project,  WSRI  integrated  existing  software  and  hardware  components  and 
deployed  the  prototype  system  as  part  of  the  Angel  Thunder  2017  exercise.  Angel  Thunder  is  the 
largest  and  most  realistic  joint  service,  multinational,  interagency  combat  search  and  rescue 
exercise  designed  to  provide  training  for  personnel  recovery  assets  using  a  variety  of  scenarios  to 
simulate  deployment  conditions  and  contingencies.  Personnel  recovery  forces  train  through  the 
full  spectrum  of  personnel  recovery  capabilities  with  ground  recovery  personnel,  air  assets. 
Special  Forces  teams  and  federal  agents. 

The  DTT  project  goals  were: 

1 .  Analysis  and  disassembly  of  existing  AFRL  LVC  software  to  create  a  modular  LVC 
training  system  and  bring  all  the  components  under  configuration  control. 

2.  Integration  of  the  components,  along  with  any  new  technologies  identified  by  AFRL 
requirements  analysis  into  the  Deployable  LVC  (DLVC)  trailer  via  the  System  Integration  Lab. 

3.  Transportation  of  the  DLVC  trailer  with  the  newly  constituted  training  system  to  the 
USAF’s  Angel  Thunder  exercise  in  AZ  and  use  the  system  to  facilitate  AFRL  training  research 
(May  2017). 

This  document  is  intended  to  be  an  initial  requirements  framework  for  a  deployable  LVC 
capability  and  uses  lessons  learned  and  observations  from  the  DTT  project  as  evidence  and 
support  for  the  capability  requirements.  This  document  also  briefly  describes  the  activities 
involved  in  preparation  and  integration  of  the  hardware  and  software  necessary  for  the  system  to 
be  deployed,  and  the  deployment  and  implementation  of  the  system  at  Angel  Thunder  as 
background. 

1. 1.  Identification 

This  document  refers  to  the  Deployable  Live,  Virtual,  and  Constructive  (DLVC)  capability  being 
developed  by  the  711*''  Human  Performance  Wing’s  Warfighter  Readiness  Research  Division, 
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Continuous  Learning  Branch  (711HPW/RHAS).  The  current  version  is  a  rough  prototype 
capability  that  heavily  leverages  the  hardware  and  software  components  of  an  After  Action 
Review  and  Data  Collection  system  originally  developed  by  Ball  Aerospace,  Aptima,  and  Cubic 
Corporation  under  the  Sensor  Integration  and  Data  Fusion  for  Operations  and  Training 
(SIDFOT)  contract. 

1.2.  Intended  Use 

The  system  is  intended  to  be  used  primarily  for  collecting  data  on  and  presenting  data  for  USAF 
operational  training  exercises.  In  addition,  it  is  intended  to  be  used  by  operators  and  cadre  to 
review  the  events  of  operational  exercises  for  learning  and  by  exercise  control  (EXCON)  or 
white  cell  personnel  for  monitoring  exercise  execution  and  gaining  situation  awareness. 

1.3.  Background 

In  this  project,  the  prototype  system  was  incorporated  into  WSRI’s  DLVC  platform  and  deployed 
to  exercise  Angel  Thunder  2017. 

The  DTT  project  began  in  October  2016  and  the  technical  effort  was  completed  by  the  end  of 
June  2017.  DTT  included  the  following  accomplishments: 

•  Collected  all  software  components  affiliated  with  AFRL.  These  are  all  of  the  pieces  of 
software  that  were  developed  for  the  SIDFOT  and  LVC  contracts,  including  the  software 
associated  with  the  sensor  grid,  the  software  components  of  the  AAR  Tool,  and  the 
components  of  the  SIDFOT  android  application. 

•  Created  git  server  projects  on  the  WSRI  git  server  for  each  of  these  collections  of  source 
code  and  baselined  them. 

•  Redesigned  the  research  network  at  the  National  Center  for  Medical  Readiness  (NCMR) 
and  DLVC.  Redesign  is  based  on  lessons  learned  during  TW  2016  and  discussions  with 
Mr.  Ted  Harmer  (711HPW/RHAS). 

•  Installed  and  configured  new  backbone  switch. 

•  Reconfigured  other  network  devices  to  accommodate  new  network  design,  including 
Force  10  Switch,  Cisco  POE  switch,  Cisco  Wireless  Access  Controller,  Cisco  Router,  2 
servers. 

•  Researched  Multicast  configurations  for  the  NCMR/DLVC  equipment. 

•  Built  S/W  CM  repository,  using  GIT,  for  DTT  software  components  and  sent  out  login 
information  for  git  repository  to  team. 

•  Completed  NCMR  network  changes. 

•  Installed  and  configured  Cisco  ASA  Eirewall  device  in  the  DLVC  trailer. 
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•  Configured  permanent  VPN  tunnel  between  the  WSRI  main  building  (loeated  at  4035 
Colonel  Glenn  Hwy)  and  NCMR  (loeated  at  506  East  Xenia  Drive  in  Fairborn).  This 
provided  a  dedieated  eonnection  between  the  software  integration  lab  (SIL)  located  at  the 
main  building  with  the  DLVC  prototyping  platform  housed  at  NCMR. 

•  Configured  client  VPN  capability  to  NCMR. 

•  Reconfigured  the  Ubiquiti  wireless  antennas  and  Tough  switches  to  enable  a  more 
efficient  and  robust  wireless  network  for  supporting  upcoming  and  future  research,  test, 
and  evaluation  events,  such  as  Angel  Thunder  17  and  TechWarrior  17. 

•  Installed  and  configured  new  network  devices  for  DLVC  trailer. 

•  Reconfigured  existing  DLVC  network  devices  and  computing  equipment. 

•  Configured  and  tested  DLVC  trailer  backhaul  capability. 

•  Completed  configurations,  downloaded  the  configuration  from  each  device  into 
individual  text  files  and  placed  those  in  the  sidfot  GIT  CM  repository. 

•  Attended  AT17  initial  planning  conference  in  Tucson,  AZ,  12-16  DEC  2016 

•  Created  first  draft  of  LVC  kit  overview  (OV-1) 

•  Documented  list  of  radio  frequencies  used  by  the  devices  in  the  LVC  kit  and  submitted 
those  to  AT  17  planning  staff  on  17  JAN  2017. 

•  Uncovered  a  risk  that  the  Milestone  XProtect  security  camera  software  that  was  then  a 
part  of  the  AFRL  kit  was  not  provided  with  source  code  or  installer  applications.  As  a 
result  (due  to  its  hardware  and  software  licensing  policies)  we  could  not  install  Milestone 
in  the  DLVC  rack.  Investigated  Wowza  and  iSpy  as  interim  solutions  to  overcome 
licensing  and  product  lifecycle  issues  with  Milestone  Xprotect. 

o  XProtect  is  the  commercial-off-the-shelf  (COTS)  solution  to  recording  video 
chosen  by  the  SIDFOT  project. 

o  iSpy  is  an  open-source  project  which  could  be  upgraded  to  include  certain  kinds 
of  software  support  with  a  paid  subscription. 

o  Wowza  is  commercial-off-the-shelf  (COTS)  software  with  an  initial  cost  and  a 
recurring  yearly  maintenance  cost. 

o  With  AFRL  concurrence,  the  team  determined  that  the  best  value  solution  to  this 
problem  was  to  use  open-source  software. 

•  Asa  mitigation  to  the  risk  of  not  being  able  to  get  a  new  piece  of  software  running 
integrated  with  the  AFRL  kit,  DTT  demonstrated  the  use  of  the  existing  AFRL  rack  in  the 
DLVC  with  the  upgraded  networking. 
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•  Unpacked  and  set  up  the  AFRL  Caesar  human  patient  simulator  inside  the  NCMR  main 
building  in  anticipation  of  testing  with  the  LVC  network.  Caesar  seemed  to  run,  but  early 
on  was  neither  addressable  by  the  LVC  network  or  addressable  or  operable  by  the 
instruetor  workstation  tablet. 

•  Investigated  whether  GoPro  video  eould  be  integrated  into  the  prototype  system. 

•  Market  research  indicated  VISLINK  HEROCast  Wireless  Transmitter  Kit  for 
GoPro  provided  the  ability  to  stream  GoPro  video  over  an  IP  addressable  network. 
This  solution  was  beyond  the  budget  for  the  DTT  projeet  (-$7500  per 
eamera/video  feed). 

•  Downloaded  and  installed  latest  firmware  for  eaeh  eamera. 

•  Testing  live  streaming  from  GoPro  eamera  to  VLC  software  was  unsueeessful. 

•  GoPro  eamera  video  streaming  to  a  smartphone  using  the  Capture  app  was 
sueeessfully  tested  as  a  possible  step  to  a  more  robust  solution. 

•  More  details  of  GoPro  integration  ehallenges  are  available  in  Annex  1 . 

•  Attended  AT  1 7  mid-planning  eonferenee  in  Tucson,  AZ,  13-16  FEB  2017 

•  Confirmed  the  deployed  loeations  were  the  Florenee  Military  Range  (FMR)  in  Florenee, 
AZ,  and  Range  3  in  the  Barry  M.  Goldwater  Range  (BMGR)  near  Gila  Bend,  AZ. 

•  Regularly  attended  eoordination  meetings  with  the  University  of  Nebraska  Medieal 
Center  team  to  plan  medieal  seenarios  and  discuss  ways  to  accomplish  human-patient  simulator 
(HPS)  interaetion. 

•  As  part  of  the  requirement  diseovery  proeess  and  working  with  Angel  Thunder  staff  to 
refine  their  expeetations  and  requirements,  the  need  for  the  AAR  system  to  be  able  to  provide 
simultaneous  playbaek  and  recording  capability  has  emerged.  We  have  begun  the  redesign  and 
reeonfiguration  of  the  networking  to  aeeommodate  this  approaeh. 

•  Diseovered  the  main  roadbloeks  to  simultaneous  playbaek  and  reeording 
operation  are  the  assumptions  that  guide  how  the  existing  SIDFOT  software  works,  whieh 
preelude  simultaneous  reeord  and  playbaek.  To  minimize  risk,  we  are  segregating  two  separate 
sides  of  the  DEVC  network  and  will  need  to  proeure  at  least  one  additional  4G  ETE  router  to 
enable  a  “day”  system  and  a  “night”  system.  Our  eomputing  arehiteeture  solution  is  assisted  by 
the  virtual  maehine  approach,  but  this  solution  will  also  need  to  leverage  the  711HPW  eomputer 
raek  in  the  DEVC  to  address  the  challenges. 

•  Chose  the  iSpy  open-souree  eamera  eontrol  software  as  our  solution  to  streaming  and 
reeording  video.  It  provides  the  most  ease-of-use,  Windows  platform  native  eode,  and  signifieant 
customization,  for  no  cost  to  the  program. 
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•  Examined  the  practieality  of  streaming  GoPro  video  aeross  the  LVC  wifi  network.  In  the 
final  analysis,  to  implement  the  most  praetieal  solution,  it  would  eost  -'$250  per  eamera  and  we 
would  still  be  left  with  questions  about  how  well  this  would  work,  as  well  as  whether  any  of  the 
PJs  would  be  willing  to  strap  on  the  eamera  paek. 

•  The  BAO  Kit  does  not  provide  an  obvious  answer  as  it  only  has  usb  2.0 
eonneetions,  likely  not  suflfieient  to  transfer  HD  video/audio  in  real  time. 

•  We  have  forwarded  this  information  on  to  71 IHPW  and  we  have  agreed  to  not 
pursue  live  streaming  GoPro  further. 

•  As  part  of  the  iSpy  camera  solution,  our  team  developed  a  video  playback  capability  (to 
be  used  with  the  AARTool)  that  will  be  synchronized  with  the  AAR  Tool.  We  expect  to  have  the 
software  completed  by  the  end  of  March  and  tested  soon  after.  It  is  a  low-risk  solution  that 
leverages  existing  web-based  solutions  for  video  playback.  A  proof  of  concept  has  already  been 
partially  developed  and  successfully  plays  back  video  being  externally  synchronized. 

•  We  have  also  spent  a  little  time  analyzing  expected  LTE  coverage  and  expected  wifi 
coverage  based  on  currently  understood  locations.  Based  on  a  cursory  terrain  analysis  and 
coverage  maps  published  by  Verizon,  we  have  reasonable  confidence  that  a  4G  ETE  router 
solution  will  work,  provided  that  external  antennas  are  pointed  appropriately  to  maximize  signal. 

•  April  activities  focused  on  testing  the  video  playback  capability.  Initial  testing  was 
successful  in  that  Axis  video  was  synchronized  during  playback.  But  the  software  was  modified 
to  include  the  ability  to  playback  GoPro  video  and  a  process  to  allow  local  playback  (on  the 
AAR  computer)  of  GoPro  video  with  remote  playback  of  Axis  video.  That  capability  was 
successfully  tested  in  walkthroughs  during  April. 

•  Eogistics  and  preparation  activities  continued  throughout  April  in  preparation  for 
deployment  to  Angel  Thunder.  The  WINK-D  trailer  maintenance  was  completed  and  the  trailer 
was  ready  for  deployment. 

•  Pinal  packing  took  place  during  the  week  of  24  April  and  both  trailer  were  readied  for 
deployment.  (An  issue  emerged  with  the  trucking  company  tasked  with  shipping  the  DEVC 
trailer,  but  WSRI  was  able  to  substitute  other  resources  to  get  the  trailer  to  Arizona.) 

•  The  team  departed  for  AZ  on  29  April  and  left  to  return  on  20  May. 

•  The  DEVC  was  successfully  deployed  to  Plorence  Military  Range  in  Plorence  Arizona  as 
part  of  the  Angel  Thunder  exercise. 

•  The  team  successfully  set  up  the  DEVC  and  WINK-D  kits  on  the  Plorence  range  as 
planned  and  set  up  the  AAR  equipment  at  Davis-Monthan  APB  during  Zero  week. 

•  Also  during  Zero  week,  the  team  successfully  integrated  the  HPS  into  the  winklr  network 
and  configured  and  deployed  a  solution  for  HPS  familiarization  training. 
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•  The  team  suceessfully  supported  all  required  training  vulnerability  periods  throughout  the 
exercise. 

•  The  DLVC  and  WINK-D  kits  worked  as  designed.  However,  the  internet  connection 
provided  by  the  Verizon  LTE  routers  proved  to  be  far  too  bandwidth  limited  and  essentially  made 
remote  AAR  playback  impossible. 

•  In  addition  to  supporting  day  and  night  vulnerability  periods  on  9  and  1 1  May,  the  team 
successfully  redeployed  the  kit  to  the  BMGR  Range  3  on  Saturday,  13  May  for  the  day  VUL. 

•  The  team  then  supported  the  final  VUL  on  1 8  May. 

•  The  Hill  camera  continued  to  have  issues  and  was  eventually  taken  offline.  It  will  need 
to  be  replaced  in  the  future. 

•  The  team  helped  troubleshoot  an  issue  with  several  phones  not  joining  the  sensor  grid  and 
we  successfully  repaired  that  issue  prior  to  the  last  VUL. 

•  The  team  packed  up  the  kit  on  19  May  and  departed  for  Dayton  on  20  May. 

1.4.  System  Overview 

Wright  State  Research  Institute  integrated  various  hardware  and  software  components  into  a 
deployable  Live,  Virtual,  Constructive  (DLVC)  simulation  system.  The  system  currently  includes 
three  basic  components:  sensors,  computing  hardware  and  software,  and  networking  hardware 
and  software.  The  current  system  is  designed  to  deploy  a  wifi  network  and  associated  computing 
resources  to  remote  locations,  enabling  the  collection  and  playback  of  ground-based  training  and 
simulation  data  on  live  ranges.  Much  of  the  software  is  the  same  software  leveraged  by  the  prior 
Sensor  Integration  and  Data  Lusion  for  Operations  and  Training  (SIDLOT)  project.  This  software 
has  been  repackaged  into  a  deployable  trailer  capability  with  additional  networking  hardware  and 
additional  and  enhanced  video  recording  capability  (in  the  form  of  GoPro  cameras  and  a  new, 
non-proprietary,  open  source  video  recording  package.) 

1.4.1.  Sensors 

The  current  sensors  include  android  phones  with  custom  applications  primarily  used  for 
personnel  tracking,  GoPro  cameras  for  first-person  view  video,  and  fixed  pan,  tilt,  zoom  cameras 
for  broader  video  recording  of  live  events. 

1.4.2.  Computing  Hardware  and  Software 

The  current  computing  hardware  and  software  includes  three  or  more  workstations  running  the 
Windows  7  operating  system  and  all  components  of  the  SIDLOT  software  suite  (see  SIDLOT 
final  report  for  more  details).  Most  of  the  current  workstations  are  rack  mounted  computers  with 
some  desktop  computers  added  to  provide  more  portability  for  after-action  review  (AAR) 
purposes. 
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1.4.3.  Networking 

The  current  system  networking  equipment  is  dominated  by  Cisco  routers  and  switches 
configured  to  allow  the  sensors  to  communicate  with  the  data  collection  computers  and  to  allow 
any  of  the  AAR  computers  to  communicate  with  the  data  collection  systems  as  well. 


Trailer  details 

•  Networking  hardware 

•  Connections  to  WAN  include: 

•  Pepwave  3G/4G 

•  LC  Fiber  optic  connections  (3) 

•  Ethernet  connections  (5/FE  and 


Generator 

•  Diesel  fuel 

•  25  hr  run  time  at  full  load 

•  50  hr  run  time  at  nominal  load 

•  120  VAC  power  receptacles  (7/20A-30A) 


Systems  Running  at  Each 
Tower: 

•  Access  Point 

*  PTZ  Camera  w/IR 


Dimensions 

•  30  ft  trailer 

•  8  h  goose  neck  (receptacle  for  ball  hitch) 

•  8.5  ft  wide 

•  1 1 .5  ft  tall  with  masts  stowed  ('>40  ft  masts  extended) 

•  19.600  lbs  fully  loaded  weight  (4200  lb  kingpin  weight) 


•  Workstations  (4) 

•  Room  for  additional  workstations/laptops  when  required 


Sensors 


..59H2.&.2-4GHZ  Wireless 
'500  'Yard  Range . 


Sensors 


Sensor  details 

•  Android  smartphones  with  GPS/wifi  enabled  (40) 

•  Android  tablets  wifi  enabled  (5) 

•  Zephyr  biohamesses  w/  Bluetooth  to  smartphones  (6-20+) 


Figure  1.  Deployable  LVC  System  configured  as  of  May  2017. 


In  the  future,  it  is  expected  that  the  system  will  provide  more  interfaces  to  existing  operational 
data  sources  rather  and  rely  more  on  current  operational  systems  to  provide  data.  Therefore,  the 
current  wifi  networks  and  sensors  that  the  current  system  contains  are  to  be  considered 
prototype,  proof-of-concept  capabilities  and  not  threshold  or  objective  requirements. 

1.5.  Document  Overview  and  Use 

This  document  establishes  an  initial  draft  of  Deployable  LVC  requirements  with  a  description  of 
a  current  prototype  and  lessons  learned  to  support  those  requirements  based  on  the  system’s  most 
recent  deployment  (as  of  May  2017).  The  document  should  be  used  to  collect  additional 
requirements  for  a  deployable  LVC  capability  as  more  requirements  are  learned  via 
demonstration  or  analysis. 


2.0  APPLICABLE  AND  OTHER  REFERENCED  DOCUMENTS 

Documents  that  may  be  applicable  to  defining,  illustrating,  or  expanding  these  system 
requirements  will  appear  here.  As  of  now,  this  list  is  blank.  But  as  the  requirements  are  more 
fiilly  understood  and  specified,  those  supporting  documents  will  be  listed  here. 
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2.1.  Applicable  Documents 

None 

2.2.  Other  Referenced  Documents 

None 

3.0  DEFINITIONS,  ACRONYMS,  AND  ABBREVIATIONS 

3.1.  Definitions 

Shall  expresses  a  charaeteristic  whieh  is  to  be  present  in  the  item  which  is  the  subject  of  the 
specification,  i.e.  “shall”  expresses  a  binding  requirement. 

Should  expresses  a  target  or  goal  to  be  pursued,  but  not  necessarily  achieved. 

May  expresses  permissive  guidance. 

Will  expresses  a  declaration  of  intent  on  the  part  of  a  party,  usually  the  sponsoring  or  acquiring 
organization.  “Will”  does  not  express  a  binding  requirement.  “Will”  may  also  be  used  in  cases 
where  the  simple  future  tense  is  required,  for  example,  “The  operating  system  will  be  supplied 
by  the  government.”  Any  statement  which  employs  the  term  “will”,  if  used  in  4,  should  be 
present  as  a  note  so  as  to  be  clearly  distinguishable  from  requirements.  Will  may  also  express 
simple  futurity. 

3.2.  Acronyms 


711HPW/RHAS 

The  Air  Eorce  Research  Eaboratory’s  711th  Human  Performance  Wing, 
Warfighter  Readiness  Research  Division,  Continuous  Teaming  Branch 

AAR 

After  Action  Review 

AFRL 

Air  Eorce  Research  Eaboratory 

DIS 

Distributed  Interactive  Simulation 

DLVC 

Deployable  Eive,  Virtual,  Constmctive  capability 

EXCON 

Exercise  Control 

JTEN 

Joint  Training  and  Experimentation  Network 

NCMR 

National  Center  for  Medical  Readiness 

SADE 

Situational  Awareness  Data  Tank 

SIDEOT 

Sensor  Integration  and  Data  Eusion  for  Operations  and  Training 

8 

DISTRIBUTION  A.  Approved  for  public  release:  distribution  unlimited.  Cleared  Jan  3,  2018,  88ABW-2018-0012. 


WINK-D 


WiFi  Network  Kit-Deployable 
WSRI  Wright  State  Researeh  Institute 

3.3.  Abbreviations 
F  Fahrenheit 
gph  Gallons  per  hour 
kW  Kilowatts  of  eleetrieal  power 
mph  Miles  per  hour 
4.0  REQUIREMENTS 

4.1.  Identification  of  External  Interfaces 

Link- 16  (eventually  via  JRE/ACE  lOS) 

DIS 

JTEN 

Mierowave 

Internet 

SADE  (eventually  via  JRE/ACE  lOS) 

UHE  (eventually  ANW2,  SRW,  Voiee) 

4.2.  System  Function  and  Performance  Requirements 

The  following  system  funetion  requirements  are  those  that  are  known  at  this  time.  For  many  of 
the  eurrently  understood  requirements,  standards  of  performanee  have  not  yet  been  defined. 
Where  those  standards  are  well  enough  understood,  the  performanee  requirements  are  defined. 

4.2.1.  Current  Display  Function 

Current  state  of  the  exereise  -  near  real-time  data  display.  Data  to  be  displayed  inelude  entity 
information  (simulated  and  live)  on  a  map  (data  that  are  geographieally  and  temporally  bound). 

Supporting  Data 
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The  system  eurrently  displays  the  eurrent  state  of  entity  information  on  a  2D  map  display 
leveraging  Google  Earth.  The  entity  location  and  status  is  communicated  via  an  icon  with  a 
number  corresponding  to  the  number  assigned  to  that  particular  phone.  (In  its  current 
configuration,  the  system  relies  on  Android  smartphones  running  a  custom  application  designed 
to  communicate  with  the  system  database.  Each  smartphone  is  assigned  a  number  via  the  custom 
application  and  that  number  is  then  displayed  in  Google  Earth  when  the  smartphone  is  detected 
in  the  wifi  network  and  the  device  is  added  to  the  database.)  In  addition,  the  system  also  provides 
real-time  video  data  of  the  current  exercise.  An  example  of  that  information  can  be  seen  in 
Eigure  2. 


Figure  2,  Current  system  Google  Maps  overlay  and  video  data  display. 


4.2.2.  Record  Function 

The  system  shall  provide  the  capability  to  record  entity  state  data,  video  data,  audio  data,  and  any 
other  data  required  by  exercise  controllers,  participants,  or  researchers. 

Supporting  Data 

The  current  system  records  all  exercise  data  that  it  captures,  including  entity  position,  event 
information  added  to  the  timeline,  bio  data,  video  data,  and  audio  data  in  time  synchronized  data 
stores. 
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4.2.1.  Playback  Function 

The  system  shall  provide  the  capability  to  playback  all  recorded  data  as  a  time-synchronized  data 
record.  This  record  will  be  presented  so  that  it  can  be  used  for  situation  assessment  or  after¬ 
action  review. 

Supporting  Data 

The  system  currently  allows  a  user  to  pull  up  data  on  any  recorded  exercise  for  playback. 

4.2.1.  Timeline  Function 

The  system  shall  provide  the  capability  to  display  each  recorded  or  live  exercise  as  a  function  of 
time. 

Supporting  Data 

The  current  system  provides  a  timeline  display  capability.  In  addition,  it  allows  the  user  to  add 
events  to  the  timeline  with  custom  labeling  (events  can  be  seen  in  the  timeline  in  Figure  3 
below).  The  timeline  tool  also  incorporates  the  plotting  in  time  of  rating  events  generated  by 
other  tools  in  the  kit,  such  as  the  Performance  Measurement  Tool  and  the  SPOTLITE  tool. 


Figure  3.  The  system’s  Timeline  Tool  on  the  left  and  the  Google  Map  overlay  on  the  right. 


4.2.1.  Personnel  Tracking  Function 

The  system  shall  have  the  capability  to  display  and  record  the  location  of  any  personnel  of 
interest  during  an  exercise. 

Supporting  Data 
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The  current  system  relies  on  a  smartphone  application  to  enable  this  capability  as  briefly 
described  in  the  “Current  Display”  function. 

It  is  envisioned  that  this  capability  should  be  broadened  to  ingest  data  from  DoD  standard 
personnel  tracking  technologies  already  fielded,  such  as  EPLGRS  and  others.  In  addition,  it  is 
expected  that  the  data  to  be  displayed  could  include  attributes  such  as  friendly  (blue),  enemy 
(red),  other  forces  (gray),  exercise  control  (white). 

4.2.1.  Time-synchronized  Video  Function 

The  system  shall  have  the  capability  to  record  and  playback  video  that  are  time-synchronized  to 
the  exercise  of  interest. 

Supporting  Data 

The  current  system  has  mechanisms  to  time-synchronize  all  video  data.  The  stationary  cameras 
that  are  part  of  the  system  are  all  IP-enabled  cameras  that  are  set  up  to  feed  data  back  to  a  central 
database  where  all  video  data  are  time-stamped.  Currently  however,  some  of  these  methods  are 
highly  manual.  For  example,  the  system  is  aware  of  the  time  data  for  GoPro  video,  but  only  if  a 
series  of  currently  manual  steps  are  performed  to  prepare  the  files  for  ingestion  by  the  system 
during  playback  mode.  In  addition,  there  is  no  current  method  of  streaming  GoPro  video. 

It  is  envisioned  that  the  ultimate  system  should  be  able  to  ingest  as  many  video  feeds  (of  most 
commercially  available  and  military  system  file/broadcast  formats  that  hardware  constraints 
(e.g.,  memory  and  fide  space)  will  allow.  In  addition,  any  and  all  of  these  feeds  should  be 
available  for  playback  and  all  will  be  synchronized  with  the  exercise  data. 

4.2.1.  Accessible  Participant  State  Data  Function 

The  system  should  be  able  to  collect  and  allow  researchers  and  exercise  controllers  to  monitor 
state  data  of  exercise  participants.  These  data  may  include  bio  data. 

Supporting  Data 

The  system  currently  collects  and  stores  bio  data  via  Zephyr  bioharness  devices  worn  by 
participants  carrying  cell  phones  within  the  system’s  data  collection  protocol.  The  harness  data 
are  streamed  via  Bluetooth  to  the  smartphones  running  the  custom  application  and  these  data  are 
included  in  the  Google  Earth  overlay. 

It  is  envisioned  that  the  system  in  the  future  should  enable  the  monitoring  and  recording  of  types 
of  exercise  participant  state  data  as  required.  In  addition  these  data  need  to  be  stored  in  a  way 
that  allows  researchers  to  secure  the  data  and  prevent  the  disclosure  of  sensitive  data. 

4.2.2.  Integrate  Human  Patient  Simulator  Data 

The  system  shall  have  the  capability  to  ingest  and  monitor  human  patient  simulator  (HPS)  data. 

Supporting  Data 
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The  system  eurrently  ean  enable  aeeess  to  human  patient  simulator  data  in  the  form  of  web-based 
eonneetivity  to  CAE  Caesar  and  Metiman  HPSs  that  have  been  eustom  eonfigured  to  be 
addressable  on  the  system’s  wifi  network.  In  the  future,  it  is  expeeted  that  the  system  and  the 
HPSs  themselves  will  evolve  so  that  integrating  their  data  into  the  system  will  be  essentially  plug 
and  play,  regardless  of  HPS  manufaeturer  or  model. 

4.2.1.  Integrate  Other  Entity  Data 

The  system  shall  have  the  eapability  to  ingest  and  monitor  other  data  not  previously  mentioned, 
ineluding  aireraft  information. 

Supporting  Data 

The  system  is  envisioned  to  be  able  to  ingest  aireraft  data,  espeeially  that  of  HH-60  and  HC-130 
time-spaee-position  information  (TSPI)  or  similar  data  that  will  allow  system  users  to  loeate  and 
monitor  aireraft  within  the  exereise,  their  position  and  veloeity  information,  and  other  state 
information. 

4.3.  Relationships  Between  States  and  Modes 

The  system  should  be  able  to  simultaneously  display,  reeord,  and  playbaek  data  (for  multiple 
users). 

Currently,  this  is  a  ehallenge  based  on  the  design  of  the  eurrent  prototype  system  software.  The 
solution  to  this  ehallenge  during  Angel  Thunder  2017  was  to  instantiate  two  separate  systems  (a 
DAY  system  and  a  NIGHT  system,  eaeh  eorresponding  to  the  relative  time  of  eaeh  exereise 
vulnerability  period).  This  solution  theoretically  provided  a  mechanism  for  recording  exercise 
activity  while  simultaneously  playing  back  data  from  a  different  exercise  period.  The  hardware 
in  the  DLVC,  combined  with  the  AFRL  hardware  provided  enough  computational  power  to 
enable  this  solution.  However,  the  bandwidth  required  to  push  these  data  from  the  system  to  the 
remote  after  action  review  station  exceeded  the  bandwidth  available  via  the  Verizon  LTE  system. 
(The  recording  hardware  and  software  resided  in  the  DLVC  trailer,  which  was  located  at 
Florence  Military  Range  in  Florence,  AZ,  while  the  playback  system  was  located  at  Davis- 
Monthan  AFB,  AZ.  The  only  practical  solution  to  moving  data  between  these  systems  to  enable 
playback  at  a  location  remote  to  the  recording  was  the  Verizon  LTE  network.  Unfortunately,  the 
network  capability  was  not  up  to  the  task,  often  providing  less  than  1  Mbps  at  either  location. 


4.4.  System  External  Interface  Requirements 

Network  Connectivity 

The  system  shall  have  sufficient  network  connectivity  to  enable  all  functions. 
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4.5.  System  Environmental  Requirements 

4.5.1.  Temperature 

The  system  shall  be  able  to  collect  video  and  tracking  data  in  environments  with  temperatures 
from  36  degrees  to  104  degrees  F.  This  is  a  threshold  requirement.  It  is  expected  that  the 
temperature  extremes  could  be  greater,  to  include  below  freezing  temperatures  through 
temperatures  as  high  as  114  degrees  as  an  objective  requirement. 

Supporting  Data 

Temperatures  on  the  way  to  Angel  Thunder  and  while  at  various  sites  in  and  around  the  Angel 
Thunder  exercise  varied  between  36  deg  and  104  deg  (see  Figure  Figure  4).  Temperatures  near 
Flagstaff,  AZ  during  Angel  Thunder,  even  in  June,  dipped  below  freezing  as  snow  was  reported 
at  upper  elevations.  Daytime  temperatures  in  June  near  Gila  Bend  exceeded  100  deg  regularly 
and  temperatures  in  July  of  this  year  near  Florence  have  been  reported  as  high  as  1 14  deg  F. 


Figure  4.  Temperature  extremes  recorded  during  Angel  Thunder  2017. 


4.5.2.  Precipitation 

The  system  shall  be  able  to  collect  data  in  light  to  moderate  precipitation. 

Supporting  Data 

During  the  exercise,  there  were  a  few  days  where  the  range  experienced  light  to  moderate 
precipitation. 

4.5.3.  Wind 

The  system  should  be  able  to  collect  data  in  winds  of  up  to  20  mph. 

Supporting  Data 
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It  is  estimated  that  wind  speeds  at  certain  times  during  the  exercise  were  as  high  as  20  mph,  with 
gusts  up  to  25  mph. 

4.5.4.  Dirt/Dust 

The  system  shall  be  capable  of  collecting  data  and  operating  in  a  highly  dirty/dusty  environment. 

Supporting  Data 

Our  setup  location  for  the  DLVC  trailer  during  Angel  Thunder  2017  was  in  a  dirty  and  dusty  area 
near  a  borrow  pit  on  the  Florence  Military  Range.  In  addition,  the  Military  Operations  in  Urban 
Terrain  (MOUT)  site  was  also  dirty  and  dusty,  being  located  in  desert-like  conditions  in  Florence 
AZ.  The  Range  3  location,  located  south  of  Gila  Bend,  AZ,  was  also  an  extremely  dusty  location, 
being  located  in  the  Sonoran  desert  environment  (see  Figure  5). 


Figure  5.  Examples  of  dusty  environments  in  which  system  can  he  deployed. 


4.6.  External  Resource  Utilization  Requirements 
4.6.1.  Power 

The  system  should  be  able  to  operate  with  either  external  electrical  power  or  on  power  provided 
by  a  generator. 

Supporting  Data 

The  current  DLVC  trailer  has  an  external  power  connection  for  240  volt,  3 -phase,  60  Hz  power 
and  a  generator  that  provides  an  approximately  25  kW  power  output.  It  is,  as  yet,  unknown 
exactly  how  much  power  is  drawn  by  the  DLVC  trailer  when  operating  all  components  including 
the  HVAC  component,  but  it  is  estimated  that  the  total  power  draw  currently  could  peak  as  high 
as  5  kW.  How  this  would  translate  into  additional  power  requirements  is  unknown. 
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4.6.2.  Fuel 


The  system,  when  running  on  a  generator,  should  be  able  to  store  and  use  up  to  60  gallons  of 
diesel  fuel  at  a  time.  In  addition,  the  fuel  eonsumption  rate  should  be  no  more  than  1 .5  gph. 

Supporting  Data 

The  generator  on  the  DLVC  trailer  at  the  eurrent  time  is  requiring  approximately  1.1  gph  during 
normal  operation. 

4.7.  System  Physical  Requirements 

4.7.1.  Portability 

The  system  should  be  as  portable  as  possible. 

Supporting  Data 

It  is  expeeted  that  the  ultimate  system  eould  be  earned  and  deployed  by  a  small  number  (four  or 
fewer)  of  researehers  and/or  engineers.  Therefore,  the  system  is  envisioned  to  be  able  to  be  run 
on  just  a  few  laptop/portable  eomputers  and  have  the  smallest  logistieal  footprint  possible 
(perhaps  all  components  fitting  inside  a  standard  -  8  foot-sized  pickup  truck  bed.) 

4.8.  Personnel-Related  Requirements 

4.8.1.  Manning 

The  objective  manning  requirement  should  be  a  small  footprint,  perhaps  less  than  four  people  to 
be  able  to  transport,  set  up,  operate,  maintain,  take  down,  and  return  to  home  station.  However 
the  current  manning  requirement  is  4-8  people  depending  on  how  the  system  is  deployed. 

Supporting  Data 

During  Angel  Thunder,  the  team  successfully  moved  the  WINK-D  and  DLVC  trailers  from  FMR 
to  BMGR,  unpacked  the  system,  set  it  up,  operated  it,  repacked  it,  and  transported  it  back  to 
FMR,  all  in  one  day,  with  five  people  (Bell,  Bridges,  Harchick,  Harmer,  and  Malek.)  However, 
that  move  was  highly  planned  and  controlled,  with  plenty  of  preparation  time  available.  In  a 
more  dynamic  operation,  it  is  likely  that  the  manpower  requirement  would  have  been  up  to  eight 
people. 

4.8.2.  Expertise 
Unknown 
Supporting  Data 
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4.9.  Training-Related  Requirements 

4.9.1.  System  Familiarization 

Unknown 

4.9.2.  Operational  Training 

Unknown 

4.10.  Logistics-Related  Requirements 

4.10.1.  Transport 

The  system  will  need  to  be  transportable  by  a  minimum  of  two  qualified  operators  driving 
vehieles  appropriate  for  the  task. 

Supporting  Data 

The  current  system,  which  includes  the  WINK-D  trailer  and  the  DLVC  trailer  (shown  in  Figure 
6),  requires  vehicles  and  vehicle  operators.  The  WINK-D  trailer  requires  a  %  ton  pickup  truck 
with  a  towing  package  for  long  distance  moves.  The  DLVC  trailer  requires  a  large  pickup  truck, 
a  1  14  to  2  ton  pickup  truck  with  a  dual  rear  wheel  and  a  goose  neck  hitch.  The  DLVC  trailer’s 
loaded  weight  for  Angel  Thunder  2017  was  approximately  19,500  lbs.  which  technically  requires 
that  the  driver  have  a  commercial  driver’s  license. 


Figure  6.  Both  system  trailers  shown  with  their  respectively  required  tow  vehicles. 


In  the  future,  it  is  envisioned  that  the  entire  system  (replicating  or  exceeding  current  capability) 
could  fit  in  the  bed  of  an  8  foot  pickup  truck  bed. 
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4.11.  Other  System  Qualities 

a.  reliability  (the  ability  to  perform  with  eorreet,  eonsistent  results  -  sueh  as  mean-time-between- 
failure  for  equipment); 

b.  maintainability  (the  ability  to  be  easily  servieed  and  repaired  -  such  as  mean- time -to-repair  for 
equipment); 

c.  availability  (the  ability  to  be  accessed  and  operated  when  needed); 

d.  reuseability  (the  ability  to  be  adapted  for  use  in  multiple  applications); 

e.  testability  (the  ability  to  be  easily  and  thoroughly  tested); 

f  useability  (the  ability  to  be  easily  learned  to  use,  and  easily  used  by  its  intended  user 
population); 

g.  interchangeability  of  parts  (the  ability  to  have  parts  of  the  same  part  number  interchanged 
without  necessitating  readjustment); 

h.  transportability  (the  ability  to  be  transported  from  one  location  to  another); 

i.  ease  of  set-up  (the  ability  to  be  set  up  by  one,  or  a  given  number  of,  persons); 

j.  expandability  (the  ability  to  be  easily  modified  in  response  to  potential  areas  of  growth  in 
requirements); 

k.  flexibility  (the  ability  to  be  easily  adapted  to  changes  in  mission,  threat  or  technology); 

l.  interoperability  (the  ease  of  interfacing  and/or  interoperation  with  external  systems  in  general. 


4.12.  Design  and  Construction  Requirements 

None  as  of  yet. 

4.13.  General  Design  and  Construction  Requirements 

None  as  of  yet. 

4.14.  Characteristics  of  Subordinate  Elements 

None  as  of  yet. 

4.15.  Requirements  Traceability 

N/A 
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4.16. 


Information  Security  Requirements 


4.16.1.  Multi-level  Security 

The  system  will  need  to  have  the  ability  to  manage  or  deal  with  data  and  various  levels  of  data 
classification. 

Supporting  Data 

It  is  expected  that  future  exercises  will  require  data  feeds  that  exist  at  multiple  levels  of  security 
classification.  There  are  some  activities  in  current  Angel  Thunder  exercises  which  are  classified 
or  sensitive. 

5.0  VERIFICATION  REQUIREMENTS 

None  as  of  yet. 

6.0  NOTES 


6.1.  Operational  Concept  Description 


7.0  ANNEXES 
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7.1.  Annex  1:  GoPro  Streaming  Progress  Report 
8  March  2017 


Progress 

This  section  documents  available  information  and  approaches  to  different  streaming  solutions, 
most  of  the  info  can  probably  be  skimmed. 

The  initial  idea  to  stream  the  GoPro  video  was  to  use  a  Raspberry  Pi  to  interface  between  the 
camera  and  the  WiFi  network.  This  setup  has  already  been  moderately  tested  in  previous  work 
but  it  needs  more  development  to  streamline  its  usage.  A  WiFi  hotspot  is  generated  by  the  GoPro 
so  that  the  GoPro  app  can  connect  to  it.  The  fact  that  the  camera  creates  its  own  hotspot  instead 
of  connecting  to  a  network  is  very  inconvenient.  The  GoPro  does  not  natively  support  streaming. 
However,  when  using  the  GoPro  app,  a  preview  stream  is  sent  to  the  phone  so  the  user  can 
control  the  GoPro.  This  preview  stream  can  be  accessed  by  connecting  a  laptop  to  the  GoPro’s 
wireless  network,  then  opening  the  stream  file  that  is  stored  in  a  web  server  that  is  ran  on  the 
camera.  The  URL  to  the  stream  is  “http://10.5.5.9:8080/live/amba.m3u8”. 

Since  the  GoPro’s  WiFi  hotspot  has  a  very  small  range,  and  because  having  to  connect  to  the 
cameras  WiFi  is  inconvenient,  a  Raspberry  Pi  is  used  to  interface  with  the  GoPro.  This  is  done  by 
equipping  the  Pi  with  two  wireless  NIC’s,  one  to  connect  to  the  GoPro  WiFi,  and  another  to 
connect  to  the  main  wireless  network.  Newer  Raspberry  Pi’s  have  a  built  in  WiFi  chip  which  is 
nice  so  there  is  only  one  NIC  plugged  into  a  USB  port  instead  of  two.  VLC  is  run  on  the  Pi  to 
handle  the  video  stream.  It  opens  the  preview  stream  file,  then  creates  a  RTSP  stream  so  that 
computers  connected  to  the  main  network  can  access  the  stream. 

One  of  the  issues  encountered  with  the  Raspberry  Pi  streaming  is  that  when  it  booted  up,  each 
NIC  needs  to  connect  to  the  right  network.  The  issue  is  that  if  they  don’t  connect  to  the  right 
network,  then  they  had  to  be  manually  changed.  This  required  hooking  up  a  mouse,  keyboard, 
and  monitor  to  the  Pi  which  is  cumbersome.  A  better  way  to  do  this  is  to  look  into  the  wireless 
config  files,  and  startup  scripts  to  make  sure  the  NIC’s  connect  to  the  right  network.  Another 
thing  that  needs  to  be  done  is  to  set  up  SSH  so  the  Pi  can  be  used  remotely  instead  of  hooking  up 
peripherals.  Finally,  to  stream  with  VLC,  the  stream  needs  to  be  set  up  by  clicking  through  the 
menus.  This  can  be  automated  by  using  VLC  in  the  terminal  instead  of  hooking  up  peripherals  in 
order  to  use  the  GUI. 

To  power  the  Raspberry  Pi,  a  LiPo  battery  pack  was  used.  This  battery  has  USB  ports  that  can  be 
used  to  recharge  the  pack  and  power  devices.  The  Pi  has  a  micro  USB  port  used  for  connecting  a 
power  supply.  The  dimensions  for  the  battery  pack  are  5.5  x  2.3  x  1  inches  and  weighs  0.625  lbs. 
Storage  capacity  for  the  battery  is  10,000  mAh.  At  full  load  the  Pi  consumes  about  750  mA, 
which  means  it  would  take  13.3  hours  to  drain  this  battery  pack.  Once  the  final  GoPro  solution  is 
worked  out,  a  smaller  battery  can  be  used  to  save  weight. 

Once  the  stream  is  setup  with  VLC  running  on  the  Pi,  remote  computers  can  access  this  stream. 
This  is  done  by  using  VLC  on  the  remote  machine  and  inputting  the  IP  of  the  Pi.  Future 
implementation  of  this  system  will  probably  replace  VLC  on  the  remote  computer  with  software 
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called  iSpy.  iSpy  is  an  open  source  security  camera  software  that  should  be  able  to  treat  the  Pi 
stream  as  any  other  IP  camera. 

The  disadvantage  of  getting  the  preview  stream  from  the  GoPro  through  its  WiFi  hotspot  is  that 
enabling  WiFi  reduces  the  battery  life  of  the  GoPro  significantly.  According  to  the  GoPro 
website,  the  battery  should  last  approximately  2-3  hours,  depending  on  the  video  resolution  and 
frame  rate.  Tests  were  done  to  attempt  to  match  GoPro ’s  battery  life  claims.  These  results  are 
shown  in  Table  1.  According  to  GoPro’s  website,  using  the  app  and  recording  at  1080p  60  fps, 
the  battery  should  last  1  hour  and  30  minutes.  During  the  test  it  only  lasted  55  minutes.  The  best 
result  achieved  was  using  the  app  preview,  but  not  recording,  which  yielded  1  hour  and  24 
minutes.  It  can  be  seen  that  during  real  world  tests  with  the  WiFi  enabled,  the  GoPro’s  battery 
life  is  reduced  by  around  50%.  Another  disadvantage  with  the  WiFi  approach  is  that  the 
connection  between  the  GoPro  and  the  Pi  can  drop  out,  it  seems  like  this  happens  more  often 
when  the  battery  is  getting  low. 


Table  1,  GoPro  Battery  Life  Test  Results 


Test  Setup 

Tested  Duration 

GoPro  with  app  preview,  no  recording, 

1080p60 

1  Hour  24  Minutes 

GoPro  with  app  preview,  recording,  1080p60 

55  Minutes 

GoPro  streaming  to  laptop,  recording, 

1080p60 

57  Minutes 

GoPro  streaming  to  laptop,  recording,  WVGA 
60  fps 

1  Hour  14  Minutes 

An  alternative  to  using  the  GoPro’s  WiFi  to  obtain  the  video  stream  is  to  use  the  micro  HDMI 
port  on  the  camera.  This  provides  different  challenges  because  the  Raspberry  Pi  only  has  HDMI 
output,  not  input.  A  couple  solutions  exist  to  take  HDMI  input.  One  is  to  get  an  add  on  board  for 
the  Raspberry  Pi,  another  is  to  replace  the  Pi  with  a  specialized  HDMI  encoder  that  has  wireless 
connectivity. 

After  doing  some  searching  for  Raspberry  Pi  HDMI  capture  cards,  it  appears  there  are  two 
products  that  do  this.  The  first  is  the  Auvidea  BlOl.  This  board  receives  HDMI  and  sends  the 
signal  through  the  Pi’s  CSI-2  port,  which  is  what  the  Raspberry  Pi  camera  uses.  It  seems  that  this 
product  has  been  in  development  for  several  years  and  it  is  hard  to  tell  if  it  would  work 
sufficiently  for  this  project.  The  website  for  the  BlOl  says  that  it  is  on  sale,  however  the  sale  was 
supposed  to  end  in  2015  yet  the  webpage  has  not  been  updated.  The  other  option  is  the  Lintest 
PiCapture  HDl.  This  board  works  in  a  similar  way  to  the  BlOl.  If  I  understand  correctly,  the 
difference  is  that  the  BlOl  simply  takes  HDMI  and  converts  it  to  a  format  that  the  CSI-2  bus  can 
read,  where  the  HDl  emulates  the  Raspberry  Pi  camera.  An  advantage  of  emulating  the  camera 
is  that  streaming  can  be  done  the  same  way  as  streaming  with  the  official  Raspberry  Pi  camera,  a 
program  called  Raspivid  easily  sets  up  the  stream.  There  was  not  a  lot  of  reviews  of  the  HDl,  but 
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some  forum  posts  did  indicate  that  it  worked  as  claimed.  I  also  emailed  the  developers  of  the 
HDl  describing  the  project  and  they  said  other  people  have  streamed  GoPro  using  it.  The  BlOl 
is  “on  sale”  for  70  Euros  and  ships  from  Germany,  the  HDl  is  $170. 

Auvidea  does  not  specialize  in  Raspberry  Pi  boards,  but  it  appears  their  main  products  are 
general  HDMI  encoder/decoder  boards.  One  of  their  products,  the  ElOl  has  HDMI  input  and 
WiEi  connectivity.  This  board  is  an  option  instead  of  using  the  Raspberry  Pi.  The  price  of  the 
board  with  a  case  is  around  $300-350,  this  is  cheaper  than  most  specialized  HDMI  boards  that 
are  upward  of  $1000.  A  potential  issue  is  the  power  consumption,  the  website  says  it  uses  5V  at 
3.5  W.  This  doesn’t  necessarily  mean  it  consumes  this  much  but  if  it  does  then  it  would  drain  the 
battery  pack  quickly. 

Path  Moving  Eorward 

Moving  forward,  the  best  solution  for  streaming  the  GoPro  seems  to  be  using  the  HDMI  port. 
The  PiCapture  HDl  will  take  this  HDMI  signal  and  send  it  to  the  Raspberry  Pi.  The  Pi  will  then 
send  that  stream  over  the  WiEi  network.  Once  a  prototype  system  is  built,  battery  consumption 
tests  can  be  done  to  optimize  the  size  of  the  battery  needed  for  the  completed  system. 

Purchase  Eist 


Lintest  PiCapture  HDl 

https://lintestsvstems.com/products/picapture-hdl 

UPC/EAN  Code:  706970455795 

Model  Number:  HDl 


Raspberry  Pi  3  Model  B 

https://www.amazon.com/Raspberrv-Pi-RASPBERRYPI3-MODB-lGB-Model- 

Motherboard/dp/B01CD5VC92 

Model  Number:  RASPBERRYPI3-MODB-1GB 

Micro  HDMI  Cable 

GoPro  Micro  HDMI  Cable,  6’  (only  size  they  have)  $19.99 
http://shop.gopro.eom/accessories-2/micro-hdmi-cable/AHDMC-301.html 

ASIN:  B00A3MY7KE 

Model  Number:  AHDMC-301 
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Random  Amazon  brand,  claims  it  supports  4k  resolution  so  should  be  fast  enough,  didn’t  see  any 
bad  reviews,  6’  at  $6.99 


https://www.amazon.com/Rankie-High-Speed-Supports-Ethernet- 

Retum/dp/B00Z07JYLE/ref=sr  1  3?ie=UTF8&qid=1488990376&sr=8- 

3&kevwords=micro+hdmi+eable 

ASIN:  B00Z07JYEE 

Model  Number:  R- 1 1 08-HDMI-HDMI-6ET-BKx2 

(Eooks  like  3’  is  the  smallest  cable  size) 


Battery  Pack 

Should  probably  wait  until  we  see  how  much  power  the  prototype  consumes  before  buying  a 
battery.  This  10,000  mAh  EiSB  battery  pack  costs  $12.99 

http://www.mcmelectronics.com/product/29- 

7860?scode=GS401&utm  medium=cse&utm  source=google&utm  campaign=google&scid=sc 

plp29-7860&sc  mtid=29- 

7860&gclid=Ci0KEOiA9P7FBRCtoO33  EGUtPQBElQAU  tBgK14Ii44hPSv8IaEvlx77  E2qrV 

4wPcxvXFNRv9-x7IaAuvq  8P8HAQ 

Part  Number:  29-7860 

GoPro  Alternatives 


Two  alternate  solutions  to  using  the  GoPro  are  to  use  the  official  Raspberry  Pi  camera,  or  to  use 
cell  phones  to  stream  the  video.  The  Raspberry  Pi  camera  is  small,  practically  a  breakout  board 
with  a  ribbon  cable.  It  costs  about  $30.  It  supports  I080p30,  720p60,  and  SD  resolution. 
Streaming  is  easily  done  with  the  Raspivid  program.  The  disadvantage  is  that  the  form  factor  of 
the  camera  would  be  fragile,  so  a  suitable  case  for  the  Pi  and  camera  would  have  to  be  obtained. 

The  second  alternative  is  to  use  a  cell  phone  to  stream  the  video.  The  iSpy  software  can  interact 
with  an  open  source  Android  app  called  IP  Camera.  This  app  accesses  the  phone  camera  and 
streams  this  video  as  an  IP  camera.  The  disadvantage  to  this  idea  would  be  packaging  of  the 
phone  on  the  soldier,  and  if  the  app  works  on  the  phones  that  we  have. 
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7.2.  Annex  2:  DLVC/SIDFOT  System  Startup  Instructions 


Sensor  Network 

•  For  devices  connecting  to  the  511  Vlan  (10.50. 1 1  .x)  use  this  config  on  the  ToughSwitch  Port: 
Vlanl-E,  Vlan  511-U,  Vlan  600-T 

o  Devices  would  be  AP’s  like  loco’s,  P*  gen  M2  Rockets,  Camera’s  and  AC  AP 

•  For  devices  connecting  to  the  600  Vlan  (10.50. 100.x)  use  this  config  on  the  ToughSwitch 
Port:  Vlanl-E,  Vlan  511-T,  Vlan  600-T 

o  Devices  would  be:  2“^*  Gen  Rockets,  NanoBridge’s,  and  Gen  Rocket  M5  (backhaul 
devices) 

Day  System 

•  Note:  All  IP  addresses  can  be  addressed  from  any  client  workstation  on  that  side 
(day/night)  of  the  network. 

•  Note:  Eogin  to  all  workstations  (desktops  and  VM’s)  with  username  password: 
EVCSIDEOT/EVCSIDEOT 

•  Note:  Usernames  and  passwords  for  all  ToughSwitch’ s:  ubnt/ubnt 

o  Usernames  and  passwords  for  all  Network  Gear  (loco’s.  Access  Point,  all  other 
Unifi  and  Ubiquity  gear):  ubnt/ubntWlNK 

•  Note:  To  logout  of  a  thin  client  machine  to  switch  to  another  -  Hit  the  front  power  button 
on  the  think  client  machine  once.  This  will  then  bring  up  a  small  menu  which  will  start  a 
countdown  to  auto  logoff  the  machine  and  bring  up  the  menu  to  connect  to  another  thin 
client.  Another  option  is  to  login  to  1  thin  client  and  RDP  into  the  others  (10.50.2.10, 
10.50.2.11,  10.50.2.12,  10.50.2.13) 

•  Turn  on  (assuming  they  are  off  after  a  full  shutdown,  some  will  come  on  automatically): 

o  Turn  on  UPS  -  Eargest  device  on  the  very  bottom  of  the  rack.  Hold  down  the  long 
rectangular  button  above  the  ECD  display  until  you  hear  the  power  click  on. 

o  Day  ETE  Router  -  192.168.60.5 

o  DTECH  Main  Power  Switch 

o  Scorpion  (10.50.20.10)  -  labeled  on  the  DTECH  Box 

■  Runs  DHCP,  DNS,  and  NTP  for  the  Day  network 
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■  Note:  Adjust  the  time  of  this  server.  It  will  come  online  with  the  time  it 
was  last  turned  off  with.  It  is  the  NTP  server  and  the  rest  of  the  network 
will  readjust  once  it  has  been  modified. 

o  Built  in  cisco  switch  in  DTECH  Box  with  8  cables  connected 

o  Day  Router  (Cisco  1921)  -  192.168.60.9  (password  -  CBmcOrP) 

o  Day  Switch  (Cisco  3750)  -  192.168.50.3  -  username/password 

(cisco/E=Mc2Man)  via  telnet  (PuTTY  session)  where  most  of  the  cables  are 
plugged  into 

■  Note:  currently  the  Cisco  firewall  below  this  switch  is  not  handling  trafiic, 
its  power  will  not  have  an  effect  on  the  network 


o  Turn  on  the  4  Dell  Servers 

■  These  servers  Run  the  Virtual  Machines 

■  Each  of  these  boxes  have  3  IP  addresses 

•  Thin  client  login  IP  -  10.50.1.x 

•  IP  address  of  Windows  7  running  native  on  the  box  -  10.50.2.x 

•  IP  address  of  Virtual  Machine  once  it  has  been  started  manually  - 
10.100.11.x 

o  Use  a  thin  client  workstation  and  login 

■  The  menu  will  prompt  the  user  to  select  a  machine  to  login  into 

•  These  will  be  thin  client  IP  address  -  10.50.1.x 

•  Note  -  These  IP  addresses  are  only  addressable  from  the  thin  client 
login 

■  IP  address  to  choose  from  -  select  1  at  login 

•  Note:  It  is  not  necessary  to  use  a  thin  client  to  login  to  each 
machine.  Once  you  have  logged  in  to  a  machine  via  thin  client  - 
you  can  then  Remote  Desktop  (RDP)  to  the  other  windows  boxes 
(either  10.50.2.10,  10.50.2.11,  10.50.2.12,  10.50.2.13) 

•  10.50.1.10  -  This  login  will  login  into  the  10.50.2.10  Windows 
machine  which  is  running  the  Day  Cry/ARR  Playback  box  -  Use 
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the  VMWare  Desktop  ieon  to  start  the  Cry/AAR  Desktop  Machine 
(10.100.11.69) 

•  10.50.1.11  -  This  login  will  login  into  the  10.50.2.11  Windows 
machine  which  is  running  the  RackSGX  box  -  Use  the  VMWare 
Desktop  icon  to  start  the  RackSGX  server  (10.100.11.70) 

•  10.50.1.12  -  This  login  will  login  into  the  10.50.2.12  Windows 
machine  which  is  running  the  RackAAR  box  -  Use  the  VMWare 
Desktop  icon  to  start  the  RackAAR  server  (10.100.11.72) 

•  10.50.1.13  -  This  login  will  login  into  the  10.50.2.11  Windows 
machine  which  is  running  the  RackCryengine  box  -  Use  the 
VMWare  Desktop  icon  to  start  the  RackCryengine  server 
(10.100.11.71) 

o  VPN  Server  Resides  on  this  box 

■  Open  Oracle  VM  Virtual  Box 

•  Start  “VPN  server”  (10.100.11.254) 

•  You  must  login  to  server  for  VPN  services  to 
begin 

o  On  top  menu  bar  -  Input  -> 

Keyboard  ->  Insert  Ctrl-Alt-Del 

o  Login  to  Administrator  -  Password  - 
LVCDEACON 

o  Minimize  Virtual  Box  and  continue 
running  in  background 

o  Note;  If  there  are  issues  with  the 
VPN  connection  the  issue  would 
reside  in  this  machine.  Make  sure  the 
“Routing  and  Remote  Access” 
service  is  started.  It  should  startup 
automatically  though. 

o  Note:  If  everything  is  up  and  running  and  the  network  connection  says  that  it  is 
not  connected  try  these  things: 

■  Open  a  cmd  prompt  -  ping  8. 8. 8. 8 

■  Check  the  time  of  the  Scorpion  server  (10.50.20.10) 
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•  Make  sure  NTP,  DNS  and  DHCP  services  are  running 

■  Open  time  and  date  settings.  Click  to  do  a  manual  update  from  time  server. 

■  Or  open  cmd  prompt  -  type  net  time 

•  This  may  take  a  few  minutes  to  change  the  time  on  the  task  bar 

o  Note:  To  “break  out”  of  a  VM  session  hit  CTRL+ALT,  this  will  then  bring  mouse 
and  keyboard  functions  back  to  main  computer  and  out  of  the  VM. 

o  The  Ethernet  cable  from  the  TS  Pro  (10.50.100.9)  should  be  plugged  into  port  1 
on  the  cisco  main  day  switch  (this  is  labeled  on  the  switch)  and  connected  to  port 
1  on  the  TS  Pro  switch  (also  labeled) 

o  Note;  This  system  also  contains  the  40TB  NAS  (10.50.20.19).  The  E;  drive  is 
where  most  storage  is  contained.  The  drive  can  be  located  by  entering 
\\10.50.20.19\e  into  a  windows  explorer  window  or  creating  a  permanent  mapping 
of  the  drive. 

o  The  DAY  system  should  now  he  up  and  running.  Ready  to  run  an  exercise. 


Night  System 

•  Note:  Eogin  to  all  workstations  (desktops  and  VM’s)  with  username  password; 
LVCSIDFOT/EVCSIDEOT 

•  Note;  Just  as  with  the  Day  system  make  sure  the  power,  lower  rack  UPS  and  ETE  router 
have  been  turned  on 

•  Turn  on  the  “NIGHT  CRY\AAR  DESKTOP”  Workstation  (10. 100. 1 1 .60) 

•  Locate  the  VM  Ware  Application  on  the  Desktop  and  start  the  Night  Cry\AAR  Virtual 
Machine  (10.100.11.69) 

o  There  is  a  purple  desktop  sticky  note  indicating  this  server  is  the  Night  machine 

•  Power  on  the  server  blades; 

o  RackSGX  (10.100.11.70) 
o  RackCryengine  (10.100.11.71) 
o  RackAAR  (10.100.11.72) 

■  DHCP  &  VPN  Servers  Resides  on  this  box 
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Open  Oracle  VM  Virtual  Box 


o  Start  “DHCP”  server  (10.100.11.254) 
o  You  must  login  to  server  for  the  services  to  begin 

■  On  top  menu  bar  -  Input  ->  Keyboard  ->  Insert 
Ctrl-Alt-Del 

■  Login  to  Administrator  -  Password  - 
LVCDEACON 

■  Minimize  Virtual  Box  and  continue  running  in 
background 

■  Note:  If  there  are  issues  with  the  DHCP  server 
issuing  addresses  the  issue  would  reside  in  this 
machine.  Make  sure  the  “DHCP  Server”  service  is 
started.  It  should  startup  automatically  though. 

■  Note:  If  there  are  issues  with  the  VPN  connection 
the  issue  would  reside  in  this  machine.  Make  sure 
the  “Routing  and  Remote  Access”  service  is  started. 
It  should  startup  automatically  though. 

•  Remove  the  cable  from  the  TS  Pro  to  the  Day  Switch  located  in  the  Cisco  3570  Port  1, 
and  move  it  Port  8  labeled  on  the  Cisco  SG500 

•  The  NIGHT  system  should  now  he  up  and  running.  Ready  to  run  an  exercise. 


Shutdown  Procedure 
Day  System 

•  Login  to  each  workstation  (username/password:  LVCSIDFOT/LVCSIDFOT)  and  push 
shutdown.  If  shutdown  is  not  an  option  in  a  remote  desktop  session  open  a  cmd  prompt 
window  and  type:  shutdown  -s  -t  0 

•  The  systems  are: 

o  10.50.2.10 
o  10.50.2.11 
o  10.50.2.12 
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o 


10.50.2.13 


o  10.50.20.19  -NAS 

o  10.50.20.20  -  Discovery  (might  or  might  not  be  on.  Used  primarily  as  a  baekup 
server  and  is  used  to  PuTTY  into  network  gear) 

o  10.50.20.10  -  Seorpion 

•  Do  not  need  to  worry  about  network  gear.  It  will  shut  down  fine  when  the  power  is  turned 
off. 

•  Manually  turn  olf  the  DTECH  UPS  switch 

•  Manually  turn  olf  the  main  server  UPS  in  the  raek 

•  Turn  off  the  main  breaker  in  the  DLVC  panel 

Night  System 

•  Login  to  eaeh  workstation  (username/password:  LVCSIDFOT/LVCSIDFOT)  and  push 
shutdown.  If  shutdown  is  not  an  option  in  a  remote  desktop  session  open  a  cmd  prompt 
window  and  type:  shutdown  -s  -t  0 

o  The  systems  are: 

■  1 0. 1 00. 1 1 .60  -  The  workstation  running  the  Night  Cry/ AAR  Box 

■  10.100.11.70 

■  10.100.11.71 

■  10.100.11.72 

•  Do  not  need  to  worry  about  network  gear.  It  will  shut  down  fine  when  the  power  is  turned 
off. 

•  Manually  turn  off  the  main  server  UPS  in  the  raek 

•  Turn  off  the  main  breaker  in  the  DLVC  panel 

VPN  Instructions 

•  In  windows  “Setup  a  new  Network  Connection”  from  the  Network  and  Sharing  Center 
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o  Connect  to  a  workplace 

o  Create  a  new  connection,  assuming  the  connection  hasn’t  already  been  connected 
o  Use  My  Internet  Connection  (VPN) 

o  Internet  Address  (this  will  depend  as  to  which  system  you  are  connecting  to,  Day 
or  Night) 

■  166.246.55.173  -Night 

■  166.246.55.174 -Day 

o  Destination  Name  -  Name  does  not  matter,  can  be  DLVC  Day  or  DLVC  Night. 
Just  a  reminder  to  the  user  as  to  which  connection  it  is. 

o  Username:  Administrator  Password:  LVCDEACON  (No  Domain) 

o  Finish 

o  Repeat  for  both  Networks 
•  To  connect  click  on  the  network  icon  in  the  taskbar 

o  Select  the  connection  you  wish  to  connect  to  and  connect. 
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Time  Checklist 

Is  the  time  of  this  machine  accurate? 

Login  with  LVCSIDFOT/LVCSIDFOT  for  all  machines  (*expect  for  the  two 

10.100.11.254,  Virtual  Box  machines,  use  Administrator/LVCDEACON) 

Day  System  Computer 

Computer 

VM 

Y/N 

10.50.20.10  -  Scorpion 

N/A 

10.50.2.10  -  Workstation 

10.100.11.69  -  Day  CRY/AAR  Desktop 

10.50.2.11  -  Workstation 

10.100.11.70  -  RackSGX 

10.50.2.12  -  Workstation 

10.100.11.72  -  RackAAR 

10.50.2.13  -  Workstation 

10.100.11.71  - 
RackCryEngine 

10.100.11.254* -VPN 
Server  (Oracle  Virtual 
Box  Server  on 

Desktop) 

Night  System  Computer 

10.100.11.60- 
Workstation  with  label 

10.100.11.69  -  Night  CRY/AAR  Desktop 
(VMWare  shortcut  on  desktop) 

10.100.11.70  -  RackSGX 

10.100.11.71  -  RackCryEngine 

10.100.11.72  -  RackAAR 

10.100.11.254*  (Oracle  Virtual  Box  Server  on 
Desktop) 
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Network  Flow 


Day  System 

Device 

IP  Addresses 

WWW  to  LTE  WAN 

166.246.55.174 

LTE  LAN  to  Cisco  1921 

192.168.60.5 

Cisco  1921  from  LTE 

192.168.60.9 

Cisco  1921  to  Cisco  3570  (Day  Switch) 

192.168.50.254 

Cisco  3570  from  Cisco  1921 

192.168.50.3 

Cisco  3570  to  TS  Pro 

10.50.100.1 

TS  Pro  from  Cisco  3570 

10.50.100.9 

TS  Pro  to  Network 

10.50.100.x 

Night  System 

Device 

IP  Addresses 

WWW  to  LTE  router 

166.246.55.173 

LTE  LAN  to  Asus  RTR  WAN 

192.168.60.5 

Asus  RTR  LAN  from  to  Asus  RTR  WAN 

192.168.60.9 

Asus  RTR  LAN  to  Cisco  SG500 

192.168.1.253 

Cisco  SG500  from  Asus  RTR  LAN 

192.168.1.2 

Cisco  SG500  to  TS  Pro 

10.50.100.1 

TS  Pro  From  Cisco  SG500 

10.50.100.9 

TS  Pro  to  Network 

10.50.100.x 

IP  Addresses  of  Interest 
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Device 

IP  Addresses 

CAE  Caesar 

10.50.11. 

CAE  Apollo 

SSH-  Username:  root  Password: 
metiadmin 

10.50.11.196 
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Siris  Streaming  Instructions 


•  Open  instance  of  VLC 

o  It  does  not  matter  which  machine  this  is  done  from.  VLC  is  currently  installed  on 
most  machines.  Using  the  Cry/ AAR  desktop  Machine  (Day  or  Night  -  10.100.11.69) 
will  work. 

•  Click  Media 

o  Stream 

o  Enter  this  string  in  the  source  line  (all  one  line)  depending  on  the  camera: 

■  Note:  The  stream  profile  for  the  cameras  should  take  care  of  the  username  and 
password.  If  VLC  does  prompt  for  them  use:  root/admin 

■  rtsp://  root:admin@10. 50.11. 143/onvif- 
media/media.amp?profile=quality_h264&sessiontimeout=60&streamtype=uni 
cast 

■  rtsp  ://root:  admin@  10.50.11.1 45/onvif- 
media/media.amp?profile=quality_h264&sessiontimeout=60&streamtype=uni 
cast 

o  Click  Next  to  go  to  the  “Destination  Setup”  screen 

■  In  this  select  “UDP  (legacy)”  from  the  drop  down,  also  select  “Display 
Locally” 

■  Click  Add  next  to  UDP 

■  Next 

o  On  the  “Destination  Setup”  screen  on  the  “UDP”  tab 

■  Add  the  Siris  Address:  172.97.98.146 

■  Port  -  We  have  been  given  a  block  of  ports  starting  at  5000-5009 

•  Select  a  port  and  record  it  so  that  the  next  camera  can  have  a  different 
port  than  was  already  used  with  this  setup. 

■  Click  Next 

■  Transcoding  Options 

•  Turn  off  “Active  Transcoding”  -  If  this  is  left  checked  it  will  crash 
VLC 
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•  In  the  “Profile”  Drop  Down  select  the  first  option  “Video  -  H.264  + 
MP3  (MP4)” 

•  Click  Next 

•  Clicking  “Stream  all  elementary  streams” 

•  Click  “Stream” 

•  Enter  Username  and  Password;  root  admin 

■  The  data  stream  should  now  be  up  and  running.  Repeat  for  each  additional 
camera  by  changing  the  IP  address  in  the  RTSP  stream  declaration 

o  Note:  Multiple  camera  streams  can  be  setup  from  the  same  computer.  When  one 
stream  has  started  just  click  VLC  again  on  the  desktop  and  refollow  the  steps. 

o  Note:  With  the  distance  from  the  DLVC  to  the  tower,  running  VLC  streaming, 
even  in  UDP,  bottlenecks  the  network  and  won’t  allow  other  traffic  out  of  the 
network.  This  was  repeatable,  where  a  data  stream  via  VLC  was  setup  and 
outside  internet  connectivity  then  would  fail.  Once  the  VLC  stream  was 
cancelled,  the  ability  to  access  the  internet  returned. 
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7.3.  Annex  3:  AAR  Instructions 

This  document  provides  instructions  for  operating  the  711HPW/RHAS  After-Aetion  Review 
(AAR)  System  when  deployed  as  part  of  the  overall  deployable  LVC  kit. 

These  instruetions  inelude  the  following  assumptions: 

A  KML  exercise  has  been  run. 

The  AARTool  (in  the  deployed  kit)  was  running  during  the  exereise. 

Video  was  captured  (either  GoPro  or  Axis  eamera  video). 

At  least  one  sensor  (phone  or  tablet)  was  turned  on,  running  the  SIDFOT  applieation,  and 
eonneeted  to  SGX  during  the  exereise. 

AAR  Video  Playback  Instructions 

1 .  Playback 

2.  Load  GoPro  videos 

3.  Take  card  out  of  GoPro.  Insert  into  card  reader.  Put  card  reader  in  computer. 

4.  Copy  MP4  files  from  the  SD  card.  Paste  them  into  the  appropriate  GoPro  folder,  under 
the  parent  aar  videos  folder 

5.  Run  script  to  get  MP4  in  proper  format. 

6.  VPN  into  the  field  network 

a.  Go  to  Day  or  Night  drive. 

7.  Go  to  iSpy  Files.  Choose  date.  Choose  video  folder. 

8.  Go  into  appropriate  Field  camera  (eg,  AXIS)  video  folders. 

9.  Select  all  relevant  MP4  files.  Right  click.  Click  “Create  Shortcut” 

10.  Move  all  Shortcut  links  to  the  appropriate  local  folder;  My  Documents/aar  videos 
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1 1.  In  each  local  folder  for  each  field  camera  (eg,  AXIS)-  Run  the 
create  data  xml  from  shortcut  script 

12.  Remote  desktop  to  the  SGX 

13.  SGX  -  Run  Playback  Tomcat  batch  file 

14.  Desktop  -  Open  eclipse.  Run  AAR  Tool.  Open  KML  Exercise  file. 

15.  Desktop  -  Open  AAR  Video  Playback 

16.  Desktop  -  StartP layback 

17.  When  done,  close  everything  on  desktop.  On  SGX,  run  the  killer  batch  file 

18.  In  the  My  Documents/AAR  Playback/aar-video-playback  folder,  there  is  the  config.js 
script 

19.  The  AAR  Video  Playback  utility  folder  (also  referred  to  as  the  project  root  directory)  can 
be  located  at  the  following  path; 

C:\Users\LVCSIDFOT\DocumentsAAR  Playback\aar-video-playback 


20.  Once  the  recordings  are  done,  copy  the  GoPro  videos  in  to  appropriate  folders  in  the 
AAR  video  repository  folder  (video  directory)  at  the  following  path: 

C:\Users\LVCSIDFOT\Documents\aar_videos 

Make  sure  to  create  one  folder  per  device/camera  (if  one  doesn’t  already  exist)  and  enter  those 
folder  names  in  to  the  config.js  file  located  in  the  project  root  directory. 


More  on  the  config.js  file  later 

(This  file  defines  the  top  level  directory  where  the  video  files  you  need  are  located.  Only  the 
folders  named  in  the  config.js  will  be  traversed  by  the  software.  Another  important  feature  of  this 
file  is  that  the  order  of  the  video  playback  windows  in  the  tool  is  determined  by  the  order  of  the 
folder  names  in  this  file.  Video  sources  listed  top  to  bottom  in  this  file  appear  left  to  right  and  top 
to  bottom  in  the  video  playback  tool.  If  you  want  to  change  where  a  video  appears  in  relation  to 
other  video  streams  in  the  tool,  simply  cut  and  paste  folder  names  appropriately. 

ENSFiRE  that  folder  names  listed  in  the  config.js  file  appear  exactly  as  they  do  in  the  file 
directory  structure,  are  contained  completely  within  single  quotes  (‘),  and  are  separated  by 
commas  after  every  line  except  the  last  entry  before  the  braces. 
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21.  Create  folders  for  all  the  axis  cameras  in  the  video  directory  with  the  appropriate  names 
and  also  enter  those  names  in  the  config.js  file. 


22.  Create  shortcuts  of  the  axis  camera  videos  and  copy  the  shortcuts  to  the  respective  folders 
in  the  video  directory. 


Creating  data  1  .xml  files: 


23.  The  AAR  video  playback  tool  uses  xml  files  to  know  which  files  to  load 


24.  Once  all  the  GoPro  video  files  and  Axis  camera  video  shortcuts  have  been  copied  to  their 
respective  folders  in  the  video  directory,  open  a  terminal  and  traverse  to  the  video 
directory  at  C:\Users\LVCSlDFOT\Documents\aar_videos 


25.  To  generate  the  data  files  for  the  GoPro  videos,  cd  in  to  each  GoPro  video  folder  in  a 
terminal,  and  run  the  following  command: 


>  node  ‘C:  1  Users  \L  VCSIDFOT\Documents \AAR  Playback\aar-video- 
playback\create_data_xml_goPro.js  ’ . 

Note  the  at  the  end  of  the  command  (preceded  by  a  space) 


26.  To  generate  the  data  files  for  the  Axis  camera  video  shortcuts,  cd  in  to  Axis  camera  folder 
in  a  terminal  and  run  the  following  command: 


>  node  ‘C:\Users\LVCSIDFOT\Documents\AARPlayback\aar-video- 
playback\create_data_xml Jrom_shortcut.js’ . 

Note  the  ‘.’at  the  end  of  the  command  (preceded  by  a  space) 


Running  the  AAR  Video  utility: 
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27.  To  run  the  video  playback  utility,  cd  in  to  the  project  root  directory  at 

C:\Users\LVCSIDFOT\Documents\AAR  Playback\aar-video-playback  and  run  the 
following  command; 


>  npm  start 


(Note;  this  can  also  be  accomplished  using  the  shortcut  on  the  desktop.) 


Run  shortcut  script  from  trailer.  Then  copy  the  data.xml  and  the  shortcuts 
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7.4.  Annex  3:  DTT  AAR  Notes/Lessons  Learned 

•  Timeline 

o  Prior  to  travel 

■  It  was  determined  that  the  AFRL  DWINK  towers  must  be  in  a  secure  location 
due  to  potential  theft  and  vandalism 

■  It  was  discussed  the  DLVC/AFRL  capability  would  have  to  provide  its  own 
internet  connectivity  and  power  (diesel  generator). 

•  In  the  future  having  a  more  robust  internet  connection,  at  both  the 
collection  site,  as  well  as  the  debrief  site  would  increase  success 
greatly 

•  Future  logistical  support  from  AT  staff  when  it  came  to  fuel  and 
logistical  equipment  relocation  during  the  exercise  would  be 
beneficial. 

■  LIMFAC  -  receiving  Verizon  LTE  routers  4  days  prior  to  travel  to  then 
configure  both  day/night  networks  to  work  with  them 

•  1  day  delay  while  Verizon  worked  to  get  all  3  routers  to  address  one 
another 

•  Configure  day/night  networks  to  route  traffic  through  the  LTE  routers 

•  Establish  VPN  connection  from  LTE  router  slated  for  Davis- 
Monthan,  AAR  capability,  back  to  the  day  and  night  networks 

■  Packing  the  trailer  and  towers  for  transport  took  approximately  8  hours  with 
3-4  people. 

•  Euture  -  integrate  a  master  packing  list. 

■  HPS’s  sent  directly  to  AZ 

•  Did  not  have  time  to  do  pre-integration  work  for  the  CAE  medical 
mannequins 


o  Travel  to  AT  17 

■  Logistics  Company  for  movement  of  DEVC  trailer  was  unable  to  perform  last 
minute.  An  additional  WSRI  team  member  was  recruited  last  minute,  who  had 
access  to  a  vehicle  capable  of  towing  the  DEVC,  to  tow  the  DEVC  trailer  to 
Elorence,  AZ  from  Eairborn,  OH. 
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■  3  Days  of  travel  at  10  hours,  approx,  /day. 

•  Day  1  -  Dayton  to  Joplin,  MO 

•  Day  1  -  Joplin,  MO  to  Santa  Rosa,  NM 

•  Day  3  -  Santa  Rose,  NM  to  Florenee,  AZ 

■  Flat  tire  on  F550  in  San  Jon,  NM 

•  Tire  replaeement  in  Albuquerque,  NM 
o  Arrival  at  Florenee,  AZ 

o  Zero  Week 

■  Unpaek  and  unload 

■  Range  safety  training 

■  Boot  system  and  loeate  nearest  eell  tower 

■  Reeonfigure  all  system  eomponents  to  UCT  time 

•  System  was  up  and  running  and  deployed  on  day  2 

■  Drive  to  DM  and  piekup  medieal  mannequins 

•  Test  their  eonneetivity  in  the  network 

•  Create  an  ad-hoe  network  using  a  network  switeh  and  Wi-Fi  Aeeess 
Point  for  the  familiarization  training  at  DM 

•  Transport  mannequins  baek  to  DM  for  FAM  training  with  Wi-Fi 
o  Start  of  Exereise 

■  Exereise  Day  1 

•  When  powered  on,  2  of  the  Virtual  Maehines  running  AERL  servers, 
were  unable  to  obtain  proper  IP  addresses. 

o  The  issue  through  troubleshooting  ended  up  being  a  setting 
whieh  was  automatieally  reset  in  the  host’s  network  eard 
settings  for  virtual  network  adapter  in  VMWare. 

•  During  the  night  exereise,  the  SGX  server  installed  auto  updates. 
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o  This  prompted  a  recheck  of  all  machines  the  next  morning  to 
ensure  the  windows  update  service  was  disabled. 

•  Coordination  of  time  of  events  was  unknown. 

o  Event  started  4  hours  after  expected  time 

•  Mannequins  were  not  used  during  this  exercise 

■  Exercise  Day  2 

•  East  minute  change  of  schedule  and  a  struggle  with  communication, 
lead  to  a  scramble  to  prep  and  deploy  medical  mannequins  in  time  for 
start  of  exercise 

•  Not  all  phones  which  were  “kitted  up”  showed  up  in  the  Sensor  Grid 

■  Down  day 

•  Received  all  phones  from  DM 

o  Took  phones  to  field  and  verified  their  connectivity  to  the 
winklR  network  in  an  attempt  to  troubleshoot  the  issues  with 
phones  entering  the  network  in  Exercise  Day  2 

■  Exercise  Day  3  (BMGR) 

•  Due  to  conducting  an  advanced  visit  to  the  range  the  week  prior  the 
exercise  went  very  smooth. 

•  Increased  support  from  AERL  allowed  for  rapid  deployment  of  the 
system. 

•  Prior  determination  of  what  were  the  minimum,  yet  required 
components  for  a  rapid  deployment,  greatly  decreased  setup  and 
teardown  timeframes 

■  Down  Day 

•  Received  all  phones  from  DM  with  AERL  assistance  throughout  the 
day  to  troubleshoot  phones  entering  the  sensor  grid  once  more 

o  It  was  determined  that  the  SIDEOT  application  varied  on  the 
Android  phones. 

o  The  phones  were  then  standardized  on  the  version  of  the 
application 
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o  Retested  the  phones  eonnecting  to  the  network  as  well  as  ran  a 
practice  exercise 

■  Exercise  Day  4 

•  Mannequins  were  successfully  deployed  to  the  field 

o  Mobile  Wi-Fi  solution  (AP,  switch,  battery)  was  able  to 
successfully  allow  control  of  the  medical  mannequins  in  the 
field  and  beyond  the  Wi-Fi  network  coverage 

o  A  higher  fidelity  of  phones  populated  the  network  due  to  the 
testing  and  application  standardization  on  the  prior  down  day. 

o  End  Exercise 

o  Prep  for  Travel  Back  to  Dayton 

■  2  individuals  fulltime  doing  teardown,  packing  and  tower  retrieval  and  a  3‘'‘* 
running  equipment  to  and  from  DM 

o  Travel  Back  to  Dayton 

■  Eogistics  of  the  travel  back  was  handled  by  2  individuals.  In  the  future  2 
additional  individuals  (2  per  vehicle)  would  be  advised. 

■  3  Days  of  travel  at  10  hours,  approx,  /day. 

•  Day  1  -  Florence,  AZ  to  Santa  Rosa,  NM 

•  Day  1  -  Santa  Rosa,  NM  to  Joplin,  MO 

•  Day  3  -  Joplin,  MO  to  Fairborn,  OH 
Key  Lessons  Learned 

•  More  manning  the  better 

o  2  WSRI  reps  during  the  entire  exercise  and  transport  is  not  enough  to  handle  the  load 
of  responsibilities  and  logistics 

•  Increase  communication  at  all  levels 

•  More  prep  work  with  the  technology 

o  Time  standardization 
o  Phone  application  standardization 
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